Greptile Summary

This PR ports the "snap to max on cap exceeded" behavior from iOS to Android. When the user types an amount above the spending cap on the Transfer to Spending screen (and on the Advanced screen), the input now snaps to the current maximum rather than being silently blocked. The quarter-amount capping logic is also moved from the UI layer into the ViewModel.

• MaxExceeded snap: Both SpendingAmountScreen and SpendingAdvancedScreen now call amountInputViewModel.setSats(max, currentCurrencies) before showing the warning toast; rememberUpdatedState is correctly used for currentCurrencies in both screens so the currency state is always fresh inside the long-running LaunchedEffect.
• quarterAmount in state: The 25% calculation is moved into estimateFinalMaxSendAmount in the ViewModel and stored as quarterAmount in TransferToSpendingUiState, removing the balanceAfterFeeQuarter() helper; the test is updated to assert the new field.
• onClickMaxAmount / onClickQuarter simplification: Both UI callbacks are reduced to a single setSats call; the previous viewModel.updateLimits(amount) calls are removed on the assumption that SpendingAdvancedScreen re-derives transferValues from order.clientBalanceSat on mount.

Confidence Score: 4/5

Safe to merge for the primary happy path; the open question from the previous review thread about whether _transferValues stays consistent when the user reaches the advanced screen via the cap-snap path is the only thing worth verifying before merging.

The change is narrow and well-contained: two UI screens and one ViewModel. The currentCurrencies staleness fix is correctly applied with rememberUpdatedState in both screens. The main behavioral gap noted in the prior review thread — that the MaxExceeded snap path in SpendingAmountScreen does not call viewModel.updateLimits() — is still present and unaddressed. SpendingAdvancedScreen does re-derive transferValues via its own LaunchedEffect(order.clientBalanceSat), which may mitigate this in practice, but the alignment gap warrants a second look before merging.

The LaunchedEffect(Unit) MaxExceeded handler in SpendingAmountScreen.kt (around line 95) deserves a second look to confirm the missing updateLimits call is intentional given how SpendingAdvancedScreen re-initialises its state.

Sequence Diagram

sequenceDiagram
    participant User
    participant SpendingAmountScreen
    participant AmountInputViewModel
    participant TransferViewModel

    User->>AmountInputViewModel: "types amount > max"
    AmountInputViewModel-->>SpendingAmountScreen: emit MaxExceeded effect
    SpendingAmountScreen->>AmountInputViewModel: setSats(currentMaxAllowedToSend, currentCurrencies)
    SpendingAmountScreen->>SpendingAmountScreen: show toast

    User->>SpendingAmountScreen: tap MAX button
    SpendingAmountScreen->>AmountInputViewModel: setSats(uiState.maxAllowedToSend, currencies)

    User->>SpendingAmountScreen: tap 25% button
    SpendingAmountScreen->>AmountInputViewModel: setSats(uiState.quarterAmount, currencies)
    Note over TransferViewModel: quarterAmount pre-computed in ViewModel

    User->>SpendingAmountScreen: tap Continue
    SpendingAmountScreen->>TransferViewModel: onConfirmAmount(sats)

_{Reviews (2): Last reviewed commit: "fix: stale currencies" | Re-trigger Greptile}

I didn't implement on send flows because could cause issues on services that require exact amounts like Boltz if the user don't see that the amount was auto-capped

Updated branch via github web app because an e2e shard reported failure already, so waiting was warranted anyways.